It is known to implement, within a packet telecommunication network, a specific equipment or device—called thereafter as transparent clock—on a given network node/element (e.g. router or switch) aiming at taking into account this network element residence times—i.e. delays undergone by different synchronization packets to come across such a network element, it is also called as “transit delay” or “residence time”.
Transparent clocks are implemented on respective network elements—e.g. routers or switches—along a communication path between a given pair of master and slave clocks or Master and Slave ports, called thereafter respectively as “Master” and “Slave”. They exchange synchronization time-stamped packets aiming at distributing the time reference from the Mater to the Slave along said communication path. In this document, such time-stamped packets also called synchronization packets.
On the basis of conveying time control packets, a transparent clock can, by default, measure and inform the Slave of the associated network element residence times, said transparent clock is called as an end-to-end transparent clock. When a transparent clock is also able to measure neighboring link/path delays—said measurement method being called as the peer delay mechanism—the transparent clock is called as a peer-to-peer transparent clock.
A given pair of peer-to-peer transparent clocks are said to be “adjacent” if they are peers to each other with regards to the peer delay mechanism. Two such adjacent peer-to-peer transparent clocks can be directly connected via a network physical “link” or can by separated by a network “path” made of successive combinations of network links and network elements.
As an example of method implementing transparent clocks and time control packets, the standard IEEE 1588V2, also called Precision Time Protocol release 2 version or PTPV2, of the Institute of Electrical and Electronics Engineers (IEEE) can be considered.
In the present description, a transparent clock TC may be, as defined in the IEEE 1588V2 standard: a peer-to-peer transparent clock, “P2P TC”.
Within the specific case of a full P2P TC deployment—i.e. whereby all the possible intermediate network elements between the Master and the Slave are associated with a P2P TC—the distribution of time (or frequency) is impacted when P2P TC operations fail to guarantee a correctly synchronized frequency and/or time between the Master and the Slave. Thus, corrective and proactive actions are required to deal with P2P TC failures and especially with failures related to the peer delay mechanism.
In the present document, a network architecture with full or partial deployment of P2P TCs is called as a P2P network architecture. Similarly, when a network element is supported by a P2P TC, the term “network element” and the term “peer-to-peer transparent clock” are used interchangeably.
FIG. 1 represents a P2P network architecture comprising P2P TCs ensuring path delay measurements between each node and residence time measurements of each traversed node on the end-to-end synchronization path between the Master 106 and the Slave 108.
Although depicted with one peer delay instance per considered segment, a given link/path delay could be measured twice by two peer delay instances, each measurement instance being triggered by one or the two adjacent P2P TCs delineating the considered link/path. But, this targeted redundant operation mode suffers from strong issues especially while considering:                the objective of these two measurement instances: for a same link/path, these two measurement instances aim at covering the case when synchronization packets transmission directions change relatively to the rules imposed by the PTPV2 standard;        that both involved ports have to be capable of generating messages. It means that if a failure occurs at one side, e.g. one port unable to generate messages, then both instances fail.        
The messages exchanged within a P2P network architecture comprise different fields aiming at sharing synchronization data and/or time distribution information between the network elements. Such messages can be for instance Sync messages as defined in the IEEE 1588V2 standard. One field within the messages is particularly used in a P2P network architecture, it is called the “correction field” as defined in the IEEE 1588V2 standard.
The semantics of the correction field of exchanged messages in a P2P network architecture can cumulate up to three values:                Network element (NE) transit delays: residence time;        mean path delays, called “path delays” and;        path delay asymmetries.        
When a failure occurs within a given peer delay mechanism of such an architecture, the downstream (with regards to the time distribution direction) P2P TC has to be declared as in a FULL failure state whereas some of its remaining interesting capabilities could still be maintained for supporting the time distribution (e.g. NE residence time measurements).
The FIG. 1 represents in each NE: 1041, 1042, 1043, an associated peer-to-peer transparent clock (P2P TC): 1021, 1022, 1023. The peer delay mechanism—providing the measurement of an adjacent path delay information, also called peer delay information—allows for cumulating into the correction field CF of the Sync message with said path delay information and residence time across each NE.
The peer delay mechanism is based on a scheme which requires a mechanism for bidirectional message exchanges 120 and 130.
Considering a full failed P2P TC, while only a specific failure at the Peer delay mechanism occurs, limit reconfiguration and protection schemes and consequently yields to non-optimal and non-cost effective solutions.
More specifically, there is no defined mechanism for efficiently managing a failed peer delay mechanism within a chain of P2P TCs.
Currently if a failure is internally detected by a transparent clock itself and that the PTP TCs is declared in a failed state, reactive/proactive operations can be performed.
One solution consists in detecting the failure and replacing a synchronization path between the Master and the Slave by another valid path, like a backup synchronization path.
FIG. 2 represents such a solution in which a backup end-to-end synchronization path 110 is identified and activated in order to allow path delay and residence time measurements.
It exists some mechanisms which allow for informing the related slaves 108 of a failure event along the synchronization path without precisely advertising the specific nature of this failure event.
This advertisement allows a slave-centric approach—meaning that the reconfiguration of the synchronization path is driven by the slave—for triggering the selection of a backup path 110 avoiding the failed transparent clock. In the FIG. 2, the backup path comprises a set of NE 1044, 1045, 1046, 1047, which are associated respectively to TCs 1024, 1025, 1026, 1027 
This solution has two mains drawbacks:                It considers switching the synchronization signal on a backup path: practically, this is not always possible. For instance, when no backup path is available, switching of PTPV2 traffic to the backup path is not allowed as the former is in-band, meaning mixed with users' data traffics.        This solution does not consider the announcement of a specific partial failure event. It means that it only considers a full failure state announcement.        
A second solution consists in deploying an internal redundancy in each NE and associated TC. Internal redundancy can be used meaning that an additional protection scheme can be used locally. When the PTPV2 based path delay measurement failed then this measurement operation can be performed by another internal module.
In essence, this solution puts several implementation constraints and is not cost effective.
Indeed, these approaches require the provisioning of internal transparent clock redundancies and switching procedures—which increase the cost of the transparent clock itself—and/or significant reconfiguration times as the synchronization manager is generally a remote element usually located in a central office at the network core level.
Such significant reconfiguration times imply further Slave requirements (e.g. frequency stability, phase transients filtering) and thus an additional cost thereof.
If a failure is not internally detected by the failed/failing transparent clock itself, a reference clock might be used to control the transparent clock frequency deviation. This reference clock could be embedded either locally—i.e. either within the transparent clock or within an associated network element—or could be available through an external synchronization signal, such as a retimed bit stream. In this case, a locking system might be able to detect any deviation between the frequency carried by the retimed signal and the frequency generated by the local oscillator of the transparent clock.
Disappointingly, these methods also required additional costs, for instance in hardware element such as a Phase Locked Loop.
When using a long holdover mode, in case of failure detection, a holdover mode is triggered at the slave level, meaning that the progression of time is driven by the stability of the slave oscillator frequency. This behavior is not relevant for long time holdover. As an illustration, the Time deviation between two high quality/expensive clocks (i.e. Primary References Clocks—ITU-T G.811 characteristics) is already 2 μs per day. Typical slave clocks are far from these best-in-class clocks.